As the use of computer-based software systems and applications proliferates in areas as diverse as home use and entertainment/recreation, scientific and business computing, communications, and medical and military applications, there is an increasing demand to produce high-quality software in a timely and cost-effective manner. Errors in software can cause costly product delays and may jeopardize privacy and/or safety of the users of the software in certain situations, for example, in the case of software used in financial, medical, and/or military systems. Therefore, significant emphasis is usually given to software testing and quality assurance of software.
One aspect of software testing is compliance checking in which various requirements of a software system are typically specified in a human and/or computer-readable specification document. Such requirements include, for example, a set of functionalities (also called capabilities) the software is expected to deliver, certain special situations the software should be able to handle, and certain interfaces the software should provide, possibly to facilitate interaction with other software systems. Accordingly, compliance checking generally includes ascertaining that the functionalities described in the specification document are, in fact, provided by the software and/or various constraints, if listed in the specification document, are not violated by the software. Compliance checking may also include verifying that the functionalities provided by the software are consistent with the software architecture that describes various components of the software, and interactions among those components. In addition, compliance checking may include verifying that any supplemental configuration associated with the software, e.g., a listing of interfaces provided by the software, conforms to the requirements described in the specification document, and/or verifying that the supplemental configuration is consistent with the functionalities provided by the software and/or the software architecture.
Compliance checking can be performed once the software is ready for execution, i.e., the source code thereof has been written and compiled into a computer readable executable code. If an error is discovered during such a test, e.g., if a functionality provided is found not to be in accordance with a requirement in the specification document, the source code of the software may be modified and recompiled to obtain a modified executable code that must be retested. This testing methodology is often time consuming and costly. Moreover, to obtain a fully executable software system, the source code of all components of the software must be implemented, e.g., written by a developer, obtained from other sources, generated using a computer, etc. Awaiting implementation of all software components can add a significant delay to the overall development of the software.
In addition, in some situations, certain components of the complete software system are not available to a developer. It is not uncommon that a user of a software system may obtain some components from a developer, and generate certain other components on its own or may obtain them from a third-party vendor. Those other components may not be available to the developer, even in an executable form, typically for reasons such as those other components are the software user's proprietary, confidential property that the user may not share, or because obtaining a license from the third-party vendor is costly. In this situation, the user of the software typically specifies several requirements for the components to be supplied by the developer so that the user can integrate the various components into a complete software system. The developer is typically required to test and assure compliance of the components to be supplied by the developer with the specified requirements, even though the developer does not have access to all components of the software and, hence, cannot build a complete executable software for testing thereof.
According to some static-analysis techniques (i.e., techniques for testing a source-code implementation of a software system) various errors, including violations of some general implementation guidelines, can be detected early in a software development cycle. Thus, static analysis can avoid significant delays and costs associated with detecting these errors/violations for the first time while testing the executable software. Many static-analysis techniques, however, present some challenges to the use thereof for compliance checking.
As described above, static analysis is usually performed on the software source-code, which is typically written using a single programming language such as C, C++, JAVA™, etc. As such, many static-analysis tools are language specific, i.e., they are designed to analyze code written in only one format or language. In compliance checking, however, the software architecture (e.g., a high level description of various components of the software, and interactions among those components) may be provided in one format, e.g., plain text, Extensible Markup Language (XML), etc., while the source-code may be written in a different format/language such as C, C++, JAVA™, etc. Moreover, one part of the source code may be written in one format/language and another part may be written in a different format/language. Therefore, those static-analysis tools cannot ascertain that the requirements according to a high-level architecture specified in one format are met by an implementation described in one or more different formats. This problem may be compounded if the supplemental configuration associated with the software, such as interfaces to other components to be provided, is described in a third format.
Some known static-analysis tools may be used to test partially implemented source code, but these tools generally require at least some information about the incomplete or unavailable portions of the source code and/or components of the system. Such information is often provided in files commonly known as header files. The header files are not available, however, when certain proprietary and/or third-party-supplied components are inaccessible to the developer, as described above. As such, in various situations described above, known static analysis techniques cannot be employed effectively for compliance checking.